第3章　モジュール性

5つの基準

分解しやすさ(Decomposability)

あるソフトウェア構築手法が、ソフトウェアの問題を、単純な構造によって組み合わされ、個別に作業を進められるだけの独立性を保った、少数のより複雑ではない問題に分解するのを助けるとき、その手法は「モジュールの分解しやすさ」の基準を満たす。

組み合わせやすさ(Composability)

ある手法が、もともと開発されたのとは全く異なる環境においても、互いを自由に組み合わせることにより、新しいシステムを製作できるようなソフトウェア要素の生産を助けるならば、その手法は「モジュールの組み合わせさ」を満たす。

分かりやすさ(Understandability)

ほかのモジュールの知識を必要とせずに、あるいは最悪でも、ほかのわずかなモジュールについて知るだけで、読み手が理解できるソフトウェアの生成を助ける場合、その構築手法は「モジュールの分かりやすさ」を高める。

連続性(Continuity)

ある手法によって生み出されたソフトウェアアーキテクチャ内で、問題の仕様に小さな変更が生じた際に1つまたは少数のモジュールの変更しか引き起こさない場合、その手法は「モジュールの連続性」を満たしている。

保護性(Protection)

ある手法が、実行時にモジュール内で発生した異常な条件の影響をそのモジュール内に閉じ込めることができるか、最悪周辺の少数のモジュールにしか影響が広がらない場合、その手法は「モジュールの保護性」を満たしている。

5つの規則

直接的な写像(Direct Mapping)

ソフトウェアシステムの構築過程で考案されたモジュール構造は、それに先立つ問題領域のモデル化の過程で考案された任意のモジュール構造との互換性を維持しなければならない。

少ないインターフェース(Few Interface)

すべてのモジュールができる限り少ない数のモジュールとの通信で住むようにすべきである。

小さいインターフェース(Small Interface)

2つのモジュールが通信する場合、そこで交信される情報はできるだけ少なくするべきである。

明示的なインターフェース(Explicit Interface)

AとBの2つのモジュールが通信するときは、必ず、そのことがAまたはBあるいはその両方のテキストから明らかに分からなければならない。

情報隠蔽(Information Hiding)

どのようなモジュールであれ、モジュールを設計する人は、そのモジュールの属性の中からいくつかの属性をそのモジュールに関する正式な情報として選択し、顧客モジュールの作成者がその情報を利用できるようにしなければならない。

5つの原則

言語としてのモジュール単位(Linguistic Modular Units)の原則

モジュールは使用される言語の公文単位に対応していなければならない。

自己文書化(Self-Documentation)の原則

モジュールを設計する人は、モジュールについてのすべての情報をそのモジュールの一部として作るようにあらゆる努力をするべきである。

統一形式アクセス(Uniform Access)の原則

あるモジュールによって提供されるサービスはすべて統一された表記によって利用できなければならない。その表記はサービスが記憶領域によって実装されるか計算によって実装されるかにかかわらず一定でなければならない。

開放／閉鎖(Open-Closed)の原則

モジュールは開かれていると同時に閉じている。

単一責任選択(Single Choice)の原則

ソフトウェアシステムが選択肢を提供しなければならないとき、そのシステムの中の1つのモジュールだけがその千t買うしのすべてを把握すべきである。